Navigation and Scheduling Note: Use the "Filter by Type" option to search for individual tracks (i.e. General, Information, Software, Transportation) as well as other types, such as plenary sessions and meal breaks. Please note that each track runs simultaneously. Track-specific sessions have distinct room locations, which will be updated shortly.
We discuss how maintenance intersects with issues of burnout, visible/invisible work, and recognition, based on a study investigating these issues in free and/or open-source software (F/OSS) development projects. Although much research has been focused on the retention and motivation of contributors (many of whom are volunteers), maintainer burnout is increasingly being discussed in many communities. What aspects of the role of a maintainer and factors in a project contribute to experiences of burnout? What is the relationship between the relative in/visibility of maintenance work and experiences of burnout? Is there a difference between dropping out, stepping down, and burning out? To get at these questions, we report from a study primarily based on interviews with maintainers from a diverse range of F/OSS projects, as well as qualitative and quantitative analyses of code and communication platforms. “Burnout” is a term used in many different ways, but it works to give voice and legitimacy to a wide range of interpersonal issues that can otherwise be difficult to express for those in such projects. We find feelings of burnout can arise from both the relative invisibility of maintainer work, as well as the high visibility of maintainer roles. In the projects we examined, there can be a substantial amount of work performed behind the scenes, with a lack of appreciation or respect being a core issue for many maintainers. Yet the position of a maintainer can also be a rather public role to play, particularly for widely-used infrastructural projects, which raises the stakes of being a maintainer. In particular, we find that those in maintainer roles are often expected to be responsive to issues and concerns that arise, with few projects having formal mechanisms, policies, practices, or norms that let maintainers take breaks or hand-off responsibility.
